While software systems continue to grow in size and complexity, business demands continue to require shorter development cycles. This has led software developers to compromise on functionality, time to market, and quality of software products, for example. Furthermore, the increased schedule pressures and limited availability of resources and skilled labor can lead to problems such as inefficient testing, high development and maintenance costs, and the like. This may lead to poor customer satisfaction and a loss of market share for software developers.
To improve product quality many organizations devote an increasing share of their resources to testing and identifying problem areas related to software and the process of software development. Accordingly, it is not unusual to include a quality assurance team in software development projects to identify defects in the software product during and after development of a software product. By identifying and resolving defects before marketing the product to customers, software developers can assure customers of the reliability of their products, and reduce the occurrence of post-sale software fixes such as patches and upgrades which may frustrate their customers.
Testing and identifying problem areas related to software development may occur at different points or stages in a software development lifecycle. For example, a general software development lifecycle includes a high level requirements/design review, a detailed requirements/design review, code inspection, unit test, system test, system integration test, performance test and user acceptance test. However, as the software development lifecycle proceeds from high level requirements/design review to user acceptance test, costs for detecting and remedying software defects generally increases, e.g., exponentially. As such, software developers seek to detect and remedy software defects as early in the software development lifecycle in an effort to avoid the increased costs of detecting and remedying these software defects later in the software development lifecycle.
Complex system integration development is very expensive and considered high risk, as the majority of defects are found later in the life cycle due to the methodologies used to test projects. For example, test projects are planned inefficiently/ineffectively because there is no solution that provides real time insight necessary to find and fix defects as early as possible. For this reason, consistently accurate defect projection modeling in complex system integration testing is considered impossible absent significant project history. That is, conventionally, historical defect data for a project (e.g., a software code project) must be available in order to accurately project future defect patterns and trends for the project. This historic defect data may aid an organization in detecting software defects, in order to project future defect patterns and trends for the project.
It is known, though, that at the earliest stages of the software development lifecycle (when defects are less costly to identify and remedy), historical defect data for the project may not yet be available. That is, at the earliest stages of the software development lifecycle, no testing has yet occurred to provide the necessary historical defect data for the project. Thus, although most complex system integration project owners would like to accurately project defect rates to effectively plan release development, test, and launch activities and costs, this is often not possible since there is little or no applicable project history available, e.g., earlier in the design project.
Also, differences between historic project information and a current project frequently mean the projections using historical data will not be very accurate when compared against the actual current project results. Furthermore, the approach of using historical projects for estimation provides no guidance or useful insight into how to best adjust strategic development plans while the project is underway to reflect changed conditions. As a result, detailed estimation planning is rarely performed on many of the large and complex efforts that would most benefit from such planning. And, even when estimation planning is used, such planning remains static throughout the project, even though defects in rates other than those planned for may have been discovered during each phase of the project, and each deviation from defect expectations directly effects the defect expectations in each subsequent phase of the project, including production.
Accordingly, there exists a need in the art to overcome the deficiencies and limitations described hereinabove.